API

1. The cache and cache manager hierarchies have changed slightly in 5.1 with the introduction of BasicCache and BasicCacheContainer, which are parent classes of existing Cache and CacheContainer classes respectively. What's important is that Hot Rod clients must now code against BasicCache and BasicCacheContainer rather than Cache and CacheContainer. So previous code that was written like this will no longer compile.

import org.infinispan.Cache;  
import org.infinispan.manager.CacheContainer;  
import org.infinispan.client.hotrod.RemoteCacheManager;  
...  
CacheContainer cacheContainer = new RemoteCacheManager();  
Cache cache = cacheContainer.getCache();

Instead, if Hot Rod clients want to continue using interfaces higher up the hierarchy from the remote cache/container classes, they'll have to write:

import org.infinispan.BasicCache;  
import org.infinispan.manager.BasicCacheContainer;  
import org.infinispan.client.hotrod.RemoteCacheManager;  
...  
BasicCacheContainer cacheContainer = new RemoteCacheManager();  
BasicCache cache = cacheContainer.getCache();

Previous code that interacted against the RemoteCache and RemoteCacheManager should work as it used to:

import org.infinispan.client.hotrod.RemoteCache;  
import org.infinispan.client.hotrod.RemoteCacheManager;  
...  
RemoteCacheManager cacheContainer = new RemoteCacheManager();  
RemoteCache cache = cacheContainer.getCache();

Eviction and Expiration

1. The eviction XML element no longer defines the wakeUpInterval attribute. This is now configured via the expiration element:

   <expiration wakeUpInterval="60000"... />

2. Eviction's maxEntries is used as guide for the entire cache, but eviction happens on a per cache segment, so when the segment is full, the segment is evicted. That's why maxEntries is a theoretical limit but in practical terms, it'll be a bit less than that. This is done for performance reasons.

Transactions

1. A cache marked as TRANSACTIONAL cannot be accessed outside of a transaction, and a NON_TRANSACTIONAL cache cannot be accessed within a transaction. In 5.0, a transactional cache would support non-transactional calls as well. This change was done to be in-line with expectations set out in JSR-107 as well as to provide more consistent behavior.

2. In 5.0, commit and rollback phases were asynchronous by default. Starting with 5.1, these are now synchronous by default, to provide the guarantees required by a single lock-owner model.